1. Field of the Invention
Embodiments of the invention are related to tools used to develop application software. More specifically, embodiments of the invention provide an intelligent integrated development environment (IDE) tool for database-aware application development.
2. Description of the Related Art
Developing software applications is a complex task, and IDE tools are available to assist computer programmers with the development process. Currently, IDE tools are available to assist programmers developing applications in a variety of programming languages (e.g., Java® .net, C, C++, C#, etc.). These tools are typically configured with features such as auto-indenting, syntax highlighting, type checking, and a variety of other features that assist the development process. An IDE tool may include a text editor that visually displays errors as source code is typed, allowing a developer to correct errors before proceeding with the next line to code. Typically, IDE tools are customized for different programming languages and errors are identified based on the programming language being used by the developer, often determined by a suffix of a project file (e.g., .cpp for a C++ program or .java for a Java® program).
Although very useful, these IDE tools have a variety of limitations. For example, software applications often need to interact with a database. And application source code often includes embedded database statements. The database statements may retrieve data from, or update/insert data into, the database. In the program source code, database statements are usually specified as text strings in a database query language, such as SQL. The following source code fragment illustrates an embedded SQL query using the Java® programming language:
public interface get_data { // create connection to database @select sql= (”select column_A, column_B from database.table”); // execute sql statement // process query results}Because the query is enclosed within double-quotes, conventional IDE's treat the database statement as a text string, with no restrictions on string content. Thus, none of the features available for assisting developers or for detecting errors in the source code are applied to database statements embedded within application source code. Similarly, when a project is built from the application source code, the compiler ignores the text string and simply includes it in the compiled project. Thus, any errors in the database statement may go undetected until the application is built and executed. And even then, when the program fails to function as intended, identifying the error may be extremely difficult as the IDE does not provide any clues that the embedded database statement is the source of run-time errors.
Generally, the application program is responsible to catch any errors and send the right error messages to help identify the reason for failure. This leaves a burden on the developer to write source code to retrieve and identify the cause of the error. Upon executing the program and identifying what went wrong, the developer now goes back to the program source code to fix the problem. The process is repeated until all of the database statements in the program are perfected.
Additionally, even when database statements are written correctly, the application may not function properly in practice. That is, the database statement “works,” but does not update or retrieve records from the database as intended by the developer. Errors like this are notoriously difficult to detect and correct, as they do not manifest themselves until after the project is built and executed. Further, because the IDE ignores database statements—treating them as literal text strings—developers writing database-aware applications have to use different disconnected tools in order to accomplish their task. For example, to test the database statements, the developer may either (i) copy a database statement and paste it into another tool to execute the statement or (ii) build the project and execute it. At runtime, the database statement is executed and the results can be evaluated by the developer. If the results are not what the developer expected, then the developer can revise the query, build the application, and test it again.
These approaches diminish the developer's productivity as switching from one tool to another while in the middle of programming an application is distracting. Further, the latter approach requires the developer to wait for the whole program to be completed and run to see the results of the database statement may increase the time required to code the application, without improving application quality. That is, incrementally fixing each SQL error and running the application (and repeating this process until the whole application is complete) can introduce large delays in the development cycle.
Accordingly, as the foregoing discussion illustrates, there remains a need for an intelligent IDE tool for database-aware application development.